home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Polygon shapes < prev    next >
Encoding:
Internet Message Format  |  1996-08-01  |  4.3 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Polygon shapes
  2. Sent:        7/24/96 8:58 AM
  3. Received:    7/24/96 9:21 AM
  4. From:        Owen J. Palmer, ojpalmer@fcom.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Brian, would it make since to upload this code to the ODF Tool page? I
  9. keep checking this page hoping to find some more useful contributions
  10. such as Arni's Sketch. (I haven't written anything I feel would be
  11. useful to contribute yet.)
  12.  
  13. Also, ODF team, I keep hoping to see the port of TGridView from MacApp
  14. that has been referenced several times on the ODF Tool page. I don't
  15. care if it is incomplete or buggy. I just want a starting point for
  16. porting our "spreadsheet data view" derived from the Calc example to
  17. ODF.
  18.  
  19. Thanks,
  20. Owen Palmer
  21.  
  22. Brian Arnold wrote:
  23. > 
  24. > Howdy ODF-ers,
  25. > 
  26. > Since my ODF Draw-derived part needed polygon shapes, I patched together a
  27. > polygon shape class and a hexagon shape subclass for testing.  I'm not
  28. > proud of it, but it works well enough for a demo.  Send me e-mail if you
  29. > want the sources (there isn't much source, mostly headers ;-).  Feel free
  30. > to provide feedback (before I go off defining more subclasses for my
  31. > part...).
  32. > 
  33. > Here are some notes I kept while writing it.  It took about a day to write,
  34. > graft into my Draw (er, Sketch) part, and test.
  35. > 
  36. > o) I would pummel the person who decided OpenDoc will use fixed point
  37. > numbers.  The reason is, you can't "just use them" with literals.  I took a
  38. > six-of-one approach, coercing FW_IntToFixed on my literals, then noted ODF
  39. > sometimes takes a half-a-dozen-of-the-other approach, converting FW_Fixeds
  40. > into ints, doing math with literals, then converting back to FW_Fixeds.
  41. > "Sheesh" is all I can say.
  42. > 
  43. > o) There is incomplete support for polygons in ODF 1; here's a key function
  44. > I identified as missing (included as a static fn in my PolyShp.cpp file):
  45. > 
  46. > //--------------------------------
  47. > //      FW_CreatePolygonODShape
  48. > //  !!! Missing from FWGrUtil.cpp
  49. > //--------------------------------
  50. > 
  51. > static ODShape* FW_CreatePolygonODShape(
  52. >         Environment *ev,
  53. >         unsigned long pointCount,
  54. >         const FW_SPoint* pointArray)
  55. > {
  56. >   ODShape* shape = ::FW_NewODShape(ev);
  57. >   ::FW_SetShapeRegion(ev, shape, ::FW_CreatePolygonRegion(pointCount,
  58. >                                         pointArray));
  59. >   return shape;
  60. > }
  61. > 
  62. > o) The private ODF representation for a Polygon effectively requires that
  63. > its points fCount be initialized once and not changed.  It would be more
  64. > convenient if SetPoints() could adjust the fCount and adjust the memory
  65. > pointed to by fPoints instead of throwing an assertion when SetPoints sets
  66. > more points than fCount.
  67. > 
  68. > o) Although the ODF Polygon shape renderer has an autoCloseFrame parameter,
  69. > when I drag my polygon shapes without a closed polygon (the OD polygon
  70. > shape I assume), they are are outlined screwy.  I had to make sure my
  71. > Hexagon shape subclass includes the first point as the last point even
  72. > though the parent class Polygon shape uses autoCloseFrame as true and draws
  73. > correctly without the last point.  Did I misunderstand this parameter's
  74. > purpose, or is there a defect/limitation in the OpenDoc polygon
  75. > representation?
  76. > 
  77. > o) I had initially copied the OvalShp sources as a template for developing
  78. > the PolyShp and HexShp sources, and I noticed these very simple shapes
  79. > files pull in a lot of headers that don't appear to be needed.  How much of
  80. > this is necessary?
  81. > 
  82. > o) There are ODF <blah-blah> shapes (derived from FW_TGrRefPtr), and ODF
  83. > <blah-blah>Shape shapes (derived from FW_CShape), the latter which look
  84. > similar to the ODF Draw shape types.  What is the relationship between all
  85. > of these?  Should ODF Draw (and hence my code as well) eventually be using
  86. > the FW_CShapes instead of defining its own parallel representations?
  87. > 
  88. > o) Finally, a thank-you to those who worked on shapes in ODF and ODF Draw:
  89. > I found them generally easier to work with and much more powerful than the
  90. > MacApp shape code in my existing app, despite the very minor issues listed
  91. > above.
  92. > 
  93. > - Brian
  94. > 
  95. > ---------------------------------------------------------------
  96. > Brian Arnold                                  arnold@lumina.com
  97. > Director of Software Development
  98. > Lumina Decision Systems, Inc.            http://www.lumina.com/
  99.